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l.C INTRODUCTION 



1.0 I!3IBfiDlICIIJ2a 
i.l £yE£25£ 



This document describes the externa! specifications of the 
Internet Protocol (IP) module. IP is the Qepar taent of 
Defense (DoD) standard for what is called a level three 
protocol in the QSI Reference model. IP Is currently being 
used by various networks* including ARPANET, l? has also been 
included in the BSD 4.2 version of UNIX. 



In the CDCNET environment IP will be implemented as a level 
3B module. IP wi I I use the standard 3A software to interface 
with the real world. This will allow the IP module to make 
use of ail of the standard CDCNET network solutions. The 
general flavor of the IP interface is similar to the Xerox 
internet interface. 

1.2 Ef£Efif»i£fS 



The following manuals contain material that either defines 
the operation of the IP module and the modules it Interfaces 
to» or provides additional insight into the use of the IP 
modu I e. 

Internet Protocol 

Internet Control Hessage Protocol 

Internet Protocol Standard 

Transmission Control Protocol 

Transmission Control Protocol 

Transmission Control Protocol ERS 

Intranet 3A ESS 

DoD IP static Routing ER.S 



c 



1) 


RFC-791 




SRI 


2) 


RFC-792 




SRI 


3) 


HIL-STD- 


■1777 


DoO 


4) 


RFC-793 




SRI 


5) 


HIL-STD- 


•1778 


DoD 


6) 


ARH6866 




COC 


7) 


ARH6879 




coc 


3) 


APH7118 




CDC 
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2.0 SERVICE OVERVIEW 



2.0 5£E3tIC£-£J££fi3£IEH 

2.1 SE£MI££5_£SDMID£Q 



The services that the IP provides to the ULP can be divided 
into five basic groups* general* fragmentation/reassembly* SAP 
management* data transfer* and ICMP services. Each of these 
services is described in one of the following sections. 

2.1.1 GENERAL SERVICES 



The Internet Protocol UP) is designed to interconnect 
packet-switched communication networks to form an catnet. The 
IP transmits blocks of data* called I? datagrams* from sources 
to destinations throughout the catnet. Sources and 
destinations are hosts located on either the same network or 
connected networks. Each IP datagram is an independent entity 
unrelated to any other IP datagram. The IP module does not 
create connections or logical circuits and has no mechanism to 
promote data reliability* flow control* or sequencing. 

The IP module provides services to transport layer 
protocols and relies on the services of the lower layer 
network protocol <3A intranet). The IP module also provides a 
gateway function between networks. 

An Upper Layer Protocol (ULP) passes data to the IP module 
for delivery. The IP module packages the data as an IP 
datagram and passes it to the local network protocol (3A 
intranet) for transmission across the local network. If the 
destination host is on a local network* IP sends the datagram 
through the network directly to that host. If the destination 
host is on a remote network* then IP sends the datagram to a 
local gateway. The gateway* in turn* sends the datagram 
through the next network to the destination host* or to 
another gateway. The sequence of TP modules handling the 
datagram in transit Is called the gateway route. The gateway 
route Is based on the destination internet address. The IP 
modules share common rules for interpreting internet addresses 
to perform internet routing. 
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2.0 SERVICE OVERVIEW 
2.1.1 GENERAL SERVICES 



The IP module adds an IP header block to the front of all 
data that It receives from the ULP to create an IP datagram. 
This header block contains information including! the source 
address* the destination address* and the network par ameter s. 
The format of this header will not be described in this 
document due to the excellent description in [31. Sections 
9.1 thru 9.3 in C 3 3 describe each of the fields and its use. 



Occasionally* a gateway IP module or destination IP will 
encounter an error during datagram processing. Errors 
detected are reported yia the Internet Control Message 

Protocol (ICHP) which is implemented in the IP module. 






The interface to the IP module provides the ULP with the 
ability to specify certain properties of the transmission 
service according to its needs. The network parameters fait 
into two categories! service quality parameters and service 
options. The service options include? security labeling* 
source routing* route recording* stream identification 
ti mestamp ing* and the don't fragment flag. The service 
options are handled exclusively by the IP module and are 
implemented in full. The service quality parameters include* 
precedence* transmission mode* reliability* and speed. The 
service quality parameters are not handled by the IP module. 
The IP Routing module may use some of these parameters when 
choosing a route. The 3A Intranet layer Does not accept any 
of these parameters. 



C 
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2.0 SERVICE OVERVIEW 

2.1.2 FRAGMENTATION AND REASSEMBLY SERVICES 

2.1.2 FRAGMENTATION AND REASSEMBLY SERVICES 



WhHe traveling from source to destination* datagrams may 
need to traverse a network those maximum packet size Is 
smaller than the si?e of the datagram. To handle this 
the IP module provides the ability to fragment and 
datagrams. A gateway at the smaller-packet network 
the original datagram into pieces* called datagram 
that are small enough for transmission* The IP 
the destination host reassembles the datagram 
fragments to reproduce the original datagram. This operation 
is totally transparent to the layers above the IP layer. 



condi t ion* 
r eassemb 1 e 
f r agments 
fragments* 
module in 






v*y 
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2.0 SERVICE OVERVIEW 

2.1.3 SAP MANAGEMENT SERVICES 



2.1.3 SAP MANAGEMENT SERVICES 



AH services provided by the 
a Service Access Point (SAP). A 
set of routines which determines 
the IP nsodule and a user m 
routines are accessed through 
functions are described below. 



IP module are accessed through 
SAP is basically defined as a 
the two w«»y interface between 

odule. The IP SAP management 
global entry point s # their 



Open_sap 



O 



Cl ose.sap 



The o 

t hi ngs. 

the proto 
an entry 
Second* 
pro toco I 

into the 
address o 
the SAPid 



The c 
current iy 
protocol 
request. 



pen SAP routine does a nusnber of 
First* the protocol is checked; if 
col specified is not being used then 
is registered in the IP tables, 
the addresses of the upoer level 
(ULP) indication routines are stored 
registered entry. Finally* the 
f the IP send request routine and 
are returned. 



lose SAP routine releases a SAP 
in use and allows the associated 
to be used in a subsequent open 
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2.0 SERVICE OVERVIEW 

2.1.4 DATA TRANSFER SERVICES 



2.1.4 DATA TRANSFER SERVICES 
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Send_data The send routine Is provided by the IP 
module* and is called by the ULP to send a 
datagram out on the network. 



Vy 



Pecel ve_dat a 



The recelve_data routine Is provided by 
the UL? module* and is called by the IP to 

present a datagram received from the network. 
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2.0 SERVICE OVERVIEW 

2,1.5 INTERNET CONTROL MESSAGE SERVICE? 



2.1.5 INTERNET CONTROL MESSAGE SERVICES 



The IP module also provides a I 4 of the services of the 
Internet Control Message Protocol UCHP), These services are 
provided through an interface composed of three subroutines. 
The interface has been designed to provide complete service to 
ail IP users. Two separate indication routines are available 
to allow the user to specify the level of information that 
nill be provided. The function of each routine is described 
be I ow. 



Send_ i cmp 



c 



i c ffi p_ i nd 






This routine is provided by the IP module 
and allows the ULP to send the following ICMP 
datagrams. Any ULP can send these ICMP 
datagrams but* it is suggested that this 
routine be used with caution. When an echo* 
ti^estamp* or information request is sent the 
identifier field of the datagram is set to 
the sending protocol number to allow the 
response to be presented to the sender only. 

Network unreachable. 

Host unreachable. 

Protocol unreachable. 

Port unreachable. 

Fragmentation needed and 

Source route failed. 

Tf me-t o~l i ve exceeded in 

Fragment reassembly time 

Parameter problem. 

Source Quench. 

Network redirect. 

Host redirect. 

TO $/ network redirect. 

TOS/host redirect. 

Echo request and reply. 

Timestamp request and reply. 

Information request and reply 



This routine is provided by the ULP. The 
IP module will call this routine to present 
an indication of ail ICMP datagrams that are 
received for this host. If the ULP does not 
require this information the address may be 
specified as MIL on the open_sap request. If 



OF bit set. 

trans i t. 

exceeded. 
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2.0 SERVICE OVERVIEW 

2.1.5 INTERNET CONTROL MESSAGE SERVICES 



"> 



f\ 



OF bit set, 

trans it. 
exceeded. 



an echo* timestamp* or information reply is 
received it will be delivered to the protocol 
which is specified by the identifier field of 
the datagram. IE an echo* timestamp* or 
information request is received it will be 
delivered to all protocols. The following 
indications may be presented. 

Network unreachable. 

Host unreachable. 

Protocol unreachable. 

Port unreachable. 

Fr agmsntat i on needed and 

Source route failed. 

Ti ne-to-l i ve exceeded in 

Fragment reassembly time 

Parameter problem. 

Source Quench. 

Network redirect. 

Host redirect. 

TOS/network redirect. 

TOS/host redirect. 

Echo request and reply. 

Timestamp request and reply. 

Information request and reply. 



error_ind Most ULPs will only need indications for 
ICHP datagrams that are directed to their 
specific protocol. This routine is provided 
by the ULP and is called bv the IP module to 
present Indications of IC^P datagrams direct 
to the ULP specific protocol. Not all ICMP 
datagrams will generate an indication* the 
following indications may be ©resented to the 
UL^. 

Network unreachable. 

Host unreachable. 

Protocol unreachable. 

Port unreachable. 

Fragmentation needed and OF bit set. 

Source route failed. 

Time-to-live exceeded In transit. 

Fragment reassembly time exceeded. 

Parameter problem. 

Source Quench. 
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2.0 SERVICE OVERVIEW 

2,2 FUNCTIONAL RELATIONSHIPS 



Z*2 £UfclCII£HJAL-£EUIIQ«Sai££ 



Before the IP data transfer services can be used an I? SAP 
must be opened. Data may then be transferred as long as 
needed. When all data transfers have been completed the SAP 
shcul d be c losed. 

All IP SAPs will be opened by a user that is "well Known" 
to ail IP modules. This is because each SAP has a protocol 
identifier (PID) linked to it» and a PID can only be used by a 
single ULP. Unfortunate I y> there are only 254 PIDs available. 
For this reason* most users that need to exchange datagrams 
should work through the User Datagram Protocol (UOP) module 
instead of the IP module. 



r > 



At this level* opening a SAP can be likened to picking up 
the phone to make a call. Once the phone has been picked up> 
a number of separate calls may be made and information may be 
transferred on each call. When finished with all calls the 
phone is hung up> this is similar to closing the SAP. 
Although this analogy is not quite perfect it does show the 
basic principles of the IP module. The following oicture 
shows the modules that interface with the T! 5 module. 



Static 
Rout ing 



+- 

« 



EGP 



TCP 




IP 



+- 

i 

i 
» 



+ — 



3A Intranet 
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2.0 SERVICE OVERVIEW 



o 



2.3 EXTERNAL SERVICES UTILIZED 
2 . 3 £ai£B8AL-S££m£S-iiIILIZ£fl 



The following external interfaces are utilized by the IP 

modul e« 

2.3.1 NETWORK. LAYER 



The network layer used by the IP module will be the 3A 
Intranet layer. The 3A module will provide transparent data 
transfer between the host within a single network. The only 
input required from the IP module should be the IP datagram* 
the network identification* and the local network address of 
the destination host. It is assumed that data will have a 
non-zero probability of arriving at the destination. If the 
network interface fails* then the 3A module is expected to 
notify the IP module. 

The 3A module will provide a send routine which the IP 

module will cat! specifying the network identification* the 

local network address of the destination* and the data buffer. 

The data buffer will not be examined or changed by the 3A 

modul e. 

The IP irodule will provide a receive routine which the 3A 
module will call to present data that it has received on an IP 
network. The 3A module will specify the network number* the 
local network address of the source* and the data buffer. The 
3A module will not examine or modify the data buffer. The 
receive routine and the send routine are totally independent 
of each other and are asynchronous. 

The IP will also provide a routine which the 34 module will 
call to inform the IP module that the status of a network 
connection has changed. This routine will receive the network 
number* the networks status* the maximum datagram size* and 5 

other unused information. • 
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2.3.2 I?> STATIC ROUTING MODULE 




2.3.2 IP STATIC ROUTING MODULE 



The IP Static Routinq (IPSR) module Is responsible for 
determining the next destination for all datagrams received by 
the IP module. The IPSR keeps track of the status of each 
network tn*t I? can route datagrams to. The IPSR module will 
provide a routine which the IP module can call to obtain the 
destination of a datagram. The routine will accept the source 
address, the destination address, the network parameters, and 
the routing options from an IP datagram and return the next 
destination of the datagram and the maximum size of datagrams 
on that network. 



.,.>■ 



o 
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3.0 SERVICE DESCRIPTIONS 



3.0 S£mjC£-£ES££I2IIflSS 

3.1 SA£_flitfA££ilEl!lI-S£m££5 
3.1.1 DESCRIPTION 



This section describes the routines that Provide the SAP 
management services. A SAP is defined by a sapid and a set of 
routine addresses. The routines that provide SAP management 
are global addresses} all other services pass the addresses of 
their routines as parameters to and from the open_sap routine. 

3.1.2 EXTERNAL INTERFACES 

3,1.2.1 JLs_flfl£fl_sas-x£fliiflai 






The open SAP routine is used to register a Service Access 

Point with the IP module. The IP module allows a total of 254 

SAPs to he open at one time. Each SAP is identified by its 

SAPid value which is link»d to the protocol value. The format 
of the CY8JL interface is as follows! 

PROCEDURE ip_open_sap ( 



pr otoeol 
data. I nd 
er r or_ind 

lcmp_ind 
VAR send w req 
VAR icmo_req 
VAR sapid 
VAR status 



* . c 3 ^ $ 
ip_data_ind> 
ip_er ror_ind; 

1 p_ i cmp_ind; 
ip_.send_.req % 
io_i cmp_req } 
INTEGER? 
io_status_type) ; 



^t__*-" / 



protocol 



data_ i nd 



In 



In 



This value specifies the user 
protocol to the IP module. The IP 
module will only allow one SAP for 
each protocol number. The UL? must 
specify an appropriate value between 
1 and 254 inclusive. 

This is a pointer to a user 
supplied routine* which the IP 
module will call to present data 

messages to the ULP. 
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3.0 SERVICE DESCRIPTIONS 
3.1.2.1 ip_.open_.sap request 



error _ ind 



In 



cmp_i nd 



In 



send_r eq 



i cmp_req 



Hut 



Out 



O 



sap id 



Out 



status 



Out 



This is a oointer to a user 
supplied routine which the IP module 
will call to present ICMP 
indications that are specific to the 
protocol of the UL". If the ULP 
doesn't need these indications then 
the pointer should be set to NIL. 

This is a pointer to a user 
supplied routine which the IP module 
will calf to present all ICHP 
datagram indications. If the ULP 
doesn't need these indications then 
the pointer should he set to *IIL. 



This is a pointer to the 
modules routine to send data. 



IP 



This is a pointer to a routine 
provided by the IP module to allow 

the ULP to generate ICHP datagrams* 
It is suggested that this request be 
used very carefully. 

This is a 32 bit value that 
identifies the particular IP SAP in 
all later requests. This parameter 
is used by the IP module as a 
password value. 

This is the status of the 
request. The following values may 
be returned* 

ip_insuff!clent_ resources 

i P_pr otoco l_l 1 1 ega I 

i p_protocol_lnuse 

i p_suecessf u I 



3.1.2.2 ifi_c.i______£_£2_u,_£i 



c 



The close SAP routine is used to terminate the use of an IP 
SAP, This frees us the SAP for use by another ULP. 

PROCEDURE i p_c I o.se_s ap ( 
protocol i 0..255J 
sapid s INTEGER? 
VAR status : i o_s tatus_type ) 1 
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3.0 SERVICE DESCRIPTIONS 
3.1,2.2 ip_close_sap request 



protocol 
sapid 

status 



In 



In 



Out 



This value specifies the user 
protocol to the l& nodule. 

This is the SAMd returned on the 
original open request. 

This is the status of the 
request. The following values way 
be returned! 

ip_protocol_i 1 1 eg a I 

ip_satp_not_open 

i p_successf u I 
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3.0 SERVICE DESCRIPTIONS 
3.2 DATA TRANSFER SERVICES 






3.2 fliIA-I&£MS£f&-S£&yi££S 

3.2.1 DESCRIPTION 



The data transfer services are provided by two routines. 
The addresses of these routines are accessed through the 
open_sap routine. The send routine is provided by the IP 
module* and is called by the ULP module to send datagrams out 
onto the network. The indication routine is provided by the 
ULP module* and Is used by the IP module to present datagrams 
received from the network. Note that a send^data request does 
not elicit any response* nor does a data_ind indicate that a 
send.data request is required. The parameters on the routines 
indicate how the data is to be packaged and where to send it> 
the data buffer is not examined or changed by the IP module. 



3.2.2 EXTERNAL INTERFACES 
3.2.2.1 ifi„SSQJl_£MU*Si 



The send data routine is used to send data out on the 
network thru a previously opened SAP. The address of this 
routine is returned to the ULP when the open request is made. 



ip_send_req - ' 
header 
source 
destination 
opt i ons 
sapid 
VAR data 
VAR status 



'PROCEDURE ( 

io_beader_recj 

io_address ; 

i p_address; 

A ip_opt ion.r ecj 

INTEGER) 

buf.ptr J 

I p_status_type) J 






header 



Tn 



source 



In 



This is a record which contains 
the IP header for the datagram. The 
ULP module does not fill in the 
entire header only the user 
specified fields as noted in the 
data type section. 

This is the address of the 
sender. This address may be 
partially or co^oletely unspecified. 

This address is specified when a ULP 
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3.C SERVICE DESCRIPTIONS 
3.2.2*1 ip_send request 



dest i nat I on 
opt ions 

sap i d 
data 

status 



In 



In 



In 



In 



Out 



needs to Indicate which network 
solution the IP should use If It is 

mul t i homed. 

This is the address of the remote 
IP that the data Is being sent to. 

This is a pointer to a record 
which contains the IP options to be 
sent with the datagram. 

This is the SAPfd returned by the 
original open request. 

This is a pointer to the system 
buffer containing the data oortlon 
of the datagram. 

This is the status of the 
request. The following values may 

be returnfiJL* ; A ^ r , *^<. 

TpT^no^eTToT >P~ **SQ#~*eSOs*t- 

i p_pr otoco I _i 1 1 ega I 

i p_route_f a I led 

I p_s ap_not_open 

}p_suecessf u! 



3.2.2.2 ijB-iijia-laJIfijilfln 






The data indication routine is orovided by the ULP* and is 
used by the IP module to present data messages to the ULP. 
The format of the Cyfeil interface is as follows! 



»p_data_ind * * 
header 
source 
destl nat ion 

options 

sap id 
VAR data 



header 



source 



In 



In 



'PROCEDURE ( 

i p_header_ree? 
i p_ ad dress. j 
I o_address> 
A ip_opt ion_rec J 
INTEGER; 
huf _ptr ) j 



This is a record which contains 

the IP header from the datagram. 

This is the address of the remote 
IP module that sent this datagram. 
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3.C SERVICE DESCRIPTIONS 
3.2.2.2 ip_data indication 



dest i nat i on In 



opt j ons 



sapid 



data 



In 



In 



In 



This is the address that the 
datagram was sent to. This address 
indicates which network solution the 
datagrams was received on. 

This is a pointer to a record 
which contains the IP options 
received with the datagram. 

This is the SAPId returned by the 
original open request. 

This is a pointer to the system 
buffer containing the data portion 

of the datagram. 






f\ 
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3.0 SERVICE DESCRIPTIONS 

3.3 INTERNET CONTROL HESSAGE SERVICES 






3.3 IinESll£I-£rJliIEflL-fi£S5A££-S£aiU££5 

3.3.1 DESCRIPTION 



This section describes the routines which provide the 
interface to the ICMP functions supported by the IP module. 
All ULPs have the capability to send ICMP datagrams out on the 
network. This ability should be used with care. ULPs also 
have the option of receiving indications of all ICMP datagrams 
received from the network. The ULP selects this ootion by 
providing the address of an indication routine when it opens a 
SAP. Finally* the UL° can choose to receive indications about 
ICMP datagrtms received from the network for its specific 
protocol. This option is also selected by providing the 
address of the ULPs indication routine when the SAP is opened. 
It is assumed that most ULPs will use this last indication 
servi ce. 

3.3.2 EXTERNAL INTERFACES 



3.3.2.1 ififflfi-Sfiad-Jt£aU5St 



This routine is provided by the IP module to allow the ULP 
to send ICMP datagrams out to the network. This service must 
be used carefully to avoid flooding the network with useless 
ICMP datagrams. The format of the CYRIL Interface Is as 
f o I 1 ows. 



ip_icmp_req * ' 
source 
dest inat i on 

icmp_header 
pr otocol 
sap id 
VAR data 
VAR status 



source 



In 



destination In 



PROCEDURE { 

: ip_address; 

t ip_addressj 

J i cmp_header_r ec; 

: 0..2 55J 

i INTEGER; 

• buf_ptr| 

s i p_status_type) J 



This is the IP address of the 
sender within this 01. 

This is the IP address of the 
system which sent the datagram that 
is being rejected. 
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3.0 SERVICE DESCRIPTIONS 
3.3.2.1 icmp.send request 



iensp_ header 



pr otocof 



sap id 



data 



In 



In 



In 



In 



status 



Out 



Ci 



This is the header portion of the 

ICHP datagram that the ULP is 

requesting the IP module to 
tr ansmi t . 

This is the protocol number of 
the ULP requesting that an ICMP 
datagram be transmitted. 



TMs 

the IP 
opened. 



is the SAPid allocated by 
module when the SA 5 * was 



This is a pointer to the system 

message buffer with contains any 
data that needs to go as part of the 

ICMP datagram. 



This is the status of 
reauest. The following values 
he returned. 

ip_destination_i I legal 

ip_ inval i d_ f cmp.type 

ip_invalid_Scmp_code 

ip_sap_not_open 

i p_sour ce_i I I ega I 

I p_ successful 



the 
may 



3.3.2.2 ifi.ifiafi.iadi«ilifln 



This routine is provided by the ULP zr\<d is called by the IP 
module when an ICMP datagram is received from the network. 
The ULP can refuse to accept these indications by speciflng a 
NIL address on the ooen_sap request. The format of the Cybii 
interface is as follows? 



ip„icmp_ind * ' 
source 
dest i nat i on 
icmp_header 
sap id 
VAR data 



'PROCEDURE < 
s ip_addressj 

i io_ address? 
t i cmp_header_r eel 
J INTEGER? 
? bu?_ptr); 



source 



V/ 



In This is the I* address 

host which sent this ICHP 
out on the network. 



of the 

datagr am 
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3.0 SERVICE DESCRIPTIONS 
3.3.2.2 ip_icmp Indication 



dest I nst i on 



icmp_bea der 



sapid 



data 



In 



In 



Tn 



In 



This is the IP address of an 
entity within this 01 that the 
datagram pertains to. 

This is the header portion of the 
ICHP datagram that was received from 
the network. 

This is the SAPid allocated by 

the IP module when the SAP was 
opened. 

This is a pointer to the system 
message buffer with contains any 
data that came with the ICHP 
datagram. 






3.3.2.3 i£_££r.oi_iQdj.c.atiao 



The error indication routine is provided by the ULP and is 
used by the IP module to present indications to the ULP which 
are protocol specific. The ULP can refuse to accept these 
indications by specifing a NIL address on the open.sap 
request. The format of the Cybil interface is as follows* 



ip_error_ind * A P»0CEDURE ( 



header 
source 
destinat ion 
opt ions 

sapid 

data 

error 

bad_param 



ip_hearier_r ec J 

ip_address? 

i p_addr ess J 

A i0_optlon_r ecj 

INTEGER! 

huf _ptr J 

j p_ststus_type J 

INTEGER); 



header 



source 



In 



In 



destination In 



c 



This is a record which contains 
the IP header from the datagram. 

This is the address of the remote 
IP module that sent this datagram. 

This is the address that the 
datagram was sent to. This address 
indicates which network solution the 

datagram was received on. 
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3.0 SERVICE DESCRIPTIONS 
3.3.2.3 J p. error indication 



opt i ons 



sgp i d 



data 



error 



In 



In 



In 



O 



bad_par am 



IN 



This is a pointer to a record 
which contains the IP options 
received with the datagram. 

This is the SAPid returned by the 
original open request. 



This is a pointer 
buffer containing the 
of the datagram. 



to the system 
data nor t i on 



This is the type of error that 
occurred. The following errors are 

def i nedJ 

ip_net_unreechah le 
i p_bost_unr eacbab I e 
ip_protocol_unr each able 
i P_Por t_unr eachab! e 
ip_fragmentation_needed 
lp_route_f ai I ed 
ip_t Imeout 
ip_assemb!y_timeout 
ip.opt ion_er ror 
i p_cong«st ion 

This is the identifier of the bad 
parameter in the case of an option 
error. The identifier may have the 
f o I lowing values • 

= Version or IHl 

1 * Type of service 
?. = TotaJ length 

3 « Identi f i cat i on 

4 « Flags or fragment offset 

5 ■ T i me-to-l i ve 

6 * Protocol 

7 * Checksum 

8 « Source address 

9 « Destination address 

10 * Secur i ty oot ion 

11 « St ream id option 

12 * Pouting option 

13 * Timing option 
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3. SERVICE DESCRIPTIONS 
3.4 ERROR RECOVERY 






3.4 £££QE.S££Q^£Ei 



Although it can be assumed that the IP module will mot be 
running in a hostile user environment* it is assumed that 
users will make mistakes. Therefore* the interfaces of the IP 
module are designed to catch errors as soon as possible. Host 
errors can be caught by simply checking parameters passed into 
the IP module. In terms of the IP module this is really error 
prevention rsther than error recovery. The following list 
iteaiz.es the steos that will be taken to catch errors. 



1. Each SAP ha»s a 32 bit SAPID to identify it. The 
sapid will be generated from a counter which will be 
updated each time a SAPIO is used. This will prevent a 
user from trying to access a closed SAP and perhaps send 

data through a SAP reopened by another user. 

2. Ail parameters will be tested for legality. The 
addresses passed in the open_sap request are the only 
exceptions to this rule. It is probably not possible to 
validate the addresses completely. The compiler will 
make sure that a parameter is the correct type* so other 
than checking for NIL pointers no checks will be made. 
Therefore* the IP module could possibly fail if those 
addresses are messed up. 

3. There should he no error due to protocol that can 
make the IP module fail. If the 3A module passes bad 
information the error should be caught by parameter 
checks. 






CONTROL DAT4 PRIVATE 



c 



4-1 

DOD Internet Protocol ERS 

86/03/31 

4,0 PERFORMANCE 



4.0 ££.££gE!!Aj££ 

4.1 Q££EMXiJ£_£HASJXIE.BISII££ 



A large number of other modules are dependent on the IP 
module. It is therefore necessary that the IP module be as 
efficient as possible. Por every datagram that the IP module 
processes* a call is mnde to the IP routing module* therefore* 
part of the IP modules efficiency will depend upon the IP 
routing module. In general the following goals have been set. 

Assume* 1) Transmission rate of lOmeg bits/second. 

2) Average packet size of 500 bytes. 

3) Averaqe 2 m i cr oseconds /68000 instruction. 

Computes 1) Average 2500 packets/second. 

?) Average 400 microseconds/packet. 

3) Approximately 200 instructions/packet. 









CONTROL DATA PRIVATE 



4-2 

ODD Internet Protocol ERS 

86/03/31 



~ 4.0 PERFORMANCE 

[_} 4.2 OPERATIONAL MEASUREMENTS 






o 



4.2 U£££AIIJ3ilAl-U£ASUS£!!£iiI5 



The IP module accumulates a number of statistics which 
indicate the load that it has been working under. This 
information may fee accessed through the standard CDNA 
Statistics Command Processor. The content and basic format of 
the information provided is shown below. 

IP Statistics 



Total NuRiber of OPEN Requests * ######## 

Total Number of CLOSE Requests * ######## 
Number of SAPs Currently Open * *## 

Protocol Sent Received Packet errors 

### Packets' ####### Packets* *###*## Resource- #####•* 

Bytes* #f*#i##f# Bytes* ######### Content* ####### 

### Packets* #####*# Packets* ####### Resource* ####### 

p, y tes* ######### Bytes* ######### Content* ####### 

#*# Packets* ######* Packets* ####### Resource* ####*## 

Bytes* ######### Bytes* ######### Content* ####### 

Total Packets* ####### Packets* ####### Resource* ####### 

Bytes* #«####«*# Bytes* ####*#### Content* ####### 
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5.G FINITE STATE MACHINE 



5.0 £JSIIfi_5IAXE-SA£!iI!<£ 



The IP module wfl! use a very simple FSM. The FSM is 
composed of three states* 12 Input conditions* and 9 output 
actions. Each IP datagram will basically have it's own FSH. 
Each FSH instantiation will be identified by the source 
address* the destination address* the protocol* and the 
datagram identifier. The following sections describe the FSM. 

5.1 ESfi-aiASBA2 






SAP Closed 
(SO) 



*--> 



.-♦ 




Reassembly 
(S2) 
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5.0 FINITE STATE MACHINE 
£ ) 5.2 FSK INPUT CONDITIONS 



5.2 £5fi-I!i£UI-£DiiaiIIDfiS 



The following list contains the Input conditions to the 
FSH. Each of the input conditions wHJ> in combination with 
the current state* determine th next state and may produce an 
output action. Note that not all input conditions cause a 
change in the state* nor do ail input conditions produce an 
output action. 

(CD A valid open request is received from the ULP. 

(€2) A valid close request is received from the ULP. 

<C3) A valid send request is received from the UtP. 

<C4) A complete datagram is received from 3A. 

(C5) A fragment of a datagram is received from 3A for a local 

desti nat ion. 

<C6) A fragment of a datagram is received from 3A for a 
remote dest I nat i on. 

<C7) The assembly of a fragmented datagram is completed. 

J C 8) The timeout interval expires for a fragmented datagram 
under construction. 

(C9) A datagram is received from 3A with a checksum error. 

IC10) A datagram is received from 3A with an error other than 
a bad checksum. 

(Cll) A redirect error datagram is received from 3A. 

(C12) A general error datagram is received from 3A. 
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g^ 5.C FINITE STATE MACHINE 

yj 5.3 FSH OUTPUT ACTIONS 

5.3 OH_21JI£L ! I_A£IiaMS 



The following list contains the output actions that the FSH 
produces. These output actions are produced when the Input 
condition and the current state have the correct values. 

(AD Open the SAP. 

ik2) Close the SAP. 

<A3) Return the proper error status. 

(A4) Determine the datagrams destination and send it to the 
ULP or 3A. 

(A5) Discard the datagram. 

IA6) Discard the datagram and send an error datagram to its 
source. 

IA7) Begin or continue fragment collection. 

(A8) Call the routing module to update the status of the 
route used. 

(A9) Present the error datagram to the ULP. 
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-* 5.C FINITE STATE MACHINE 

*.A FSH TRANSITION DEFINITIONS 



4 JESiLIBAHSIIIQiLDEEJSJIIfljaS 






> 



This section shons what ths next state and output action is 
for each pair of current state and input condition 
combinations. This table determines the total behavior of the 
FStf. 

Input State 



Input 
Condi t ion 



C2 

C3 

C4 

C5 

C6 

C7 

C8 

C9 

CIO 

Cll 

CI 2 



SO SI sz 


', S1,A1 ! SI, A3 ! Sl»43 


! S0»A3 5 S0.tA2 I S0*A2 


! SO, A3 J S1*A4 ! S2,A4 


? SCA6 1 S1»A4 J S2.,A4 


J S0,A6 J S2>A7 J S2,A7 


\ S0#A6 1 S1»A4 *, S2,A4 


1 S0,A5 5 S1*A5 ! S1»A4 


1 S0»A6 t S1»A6 I S1*A6 


\ S0#A5 ! S1»A5 ! S2»A5 


I S0jA6 J S1»A6 ! S2,A6 


J S0,A8 ! SI>A8 f S2,A8 


1 S0.»A5 ! S1»A9 ! S2>A9 



c 
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6.0 LOG MESSAGES 



6.0 Lflfi_fi£SS£S£S 



The IP module Issues log Messages whenever It detects a 
function call error from either the Vl* of the lower layer 
software. A log message will also be Issued whenever a status 
command Is processed* and whenever a configuration command Is 
processed. The following is a list of each of the log 
messages generated. 

6.1 £ASAfl£I£B-££&fl£ 

Message Ids ??? 

Descriptive Messages "IP Parameter Error" 

fields? "Callers " $trtngU..20> 
"functions " Str ingt 1..20) 

"Parameters M Str lng< 1. .20) 

Example: 84/10/31 11*29.35 123456789A8C 
IP Parameter Error 
Callers Protocol_002 
Functions Send_data 
Parameters Precedence 

6.2 INI££.fcl4L-£EEQa_£QMniIIQH 

Message Ids ??? 

Descriptive Messages "IP Internal Error" 

Fields: "Description* " Str ingd. .60) 

Examples 84/10/31 lit 29, 35 123456789ABC 
IP Internal Error 
Descriptions Data structure corrupted. 
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7.0 INSTALLATION OPTIONS 



7.0 IMSIAlLAIietLQEIIflaS 



The IP module does not require any Installation options. 
All parameters are either closely dependent on the code or 
must be set dynamically when the snodule Is started or 
r econ f igured. 
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8.0 NEW DATA TYPES 



e.C M£i.fliIA_II££S 



Each user of the IP module is associated with an IP 

protocol type, There are a number of protocol types that are 

well Know to IP modules through out the DoO network. The 

following protocol types are defined by the IP module and are 
stated to be well known to this IP module. 



lp_protocc l_lp ♦.»•.» 
i p_pr otoco l_ I cmp 
ip_pr otocol.ggp . 
Ip_pr otocol_tcp . 

i p_pr otocol_udp . 
ip_, pro toco l_cdcgw 



Internal IP protocol. 
Internal ICMP protocol. 
Gateway to Gateway Protocol. 
Transmission Control Protocol. 
User Datagram Protocol. 
C C gateway module. 






AH functions provided by the IP module return a status 
code. The following status codes are returned by one or more 
of the IP functions or the IP error indication routine. 



TYPE 

ip_status_type * { 
P_assembi y 
P_congest i 
p_desti nat 
p_f r agment 
P_host_unr 
P_ insuf f ic 
p_ inval I d„ 
p_ inval i d._ 
p_net_unre 
p_option_e 
p_por t_unr 
o„pr otocol^i 
p_protocol_i 
p^pr otoco l_u 
• ip_route_f a i I 
f i p_ sap_.no t_op 
P„source.J 1 1 
P_successf u I 
lo_t imeout) J 



_timeout. { 

on» C 

I o n_ i II e g a I • t 

at ton_needed* C 

eachablejt -C 

i ent_r esources* C 

ic 

i c 

aci 

rr 

9»i 



$p_type. 

mp_c ode* 

habl e » 

or* 

chab !e* 

I legal* 

nuse* 

nreachable* 

ed» 

en* 

ega I * 

• 



C 

c 
c 
i 
f, 

£ 

I 

c 

i 

£ 

£ 

f 

c 



Timeout in reassembly. 
Mo delivery* congestion. 
Illegal dest. address. 
Can't send without frag. 
Inval id host id. 
Memory/buffer congestion. 
ICHP type incorrect* 
IC^P code incorrect. 
Inval id network I d. 
Error in option. 
Inva lid port. 
Utegai protocol number* 
Requested protocol in use. 
Inval id pr otoco I • 
Errors in strict route. 
The SAP Is not open. 
Illegal source address. 
Operation completed. 
Timeout during travel. 
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8,0 NEW DATA TYPES 



The address record used by the IP interface is shown below. 
The "f i e I ds_inuse H field is used to indicate which of the 
following fields are specified. The only time that a field 
can be unspecified is when the address is the source address 

of a send.data request. 

TYPE 

ip.address ■ RECORD 

fields_»nuse J U p_none, ip.net* ip_host» ip.both), 
network J 0. .OFFFFFF { 16} , 
host « 0..GFFFFFFU6), 

RECEND, 

ip_double_word s -90000000(16 ) . .7FFFFFFFC 16) J 



(H) 



The following record is used to describe the header used by 
the IP datagrams. This record is used by the ULP to pass the 
parameters that IP aould have to put into the header any way. 
The only part of the header that IP processes in the source 
address and the destination address. The following CYBIL code 
defines the record and indicates which field the ULP must fill 
be for e calling IP . 



TYPE 

i p_beader_r ec * RECO 

vers i on ? 

ihl s 

precedence J 

delay ' 

throughput J 

rel iabi I i ty : 

unused_f I ag_l ' 

unused_f I ag_2 * 

total_length : 

identification s 

unused_f i ag_3 : 

dont_frag 5 

more.frags : 

frag_offset s 

ti me_to_l i ve J 

protocol - 

checksum • 

source * 

destination i 
RECEHDl 



RD 
0..15* 

G..15, 

Q..7, 

BOOLEAN, 

BOOLEAN, 

BOOLEAN, 

BOOLEAN, 

BOOLEAN* 

0..0FFFFU6), 

0..QFFFFC16), 

BOOLEAN, 

BOOLEAN, 

BOOLEAN, 

0..G1FFFU6), 

0..255, 

• . 2 5 5 , 

0,.OFFFF(16), 

ip_douh le.word, 

ip^doub I e_word, 



t 

c 

r 

T 

i 
i 

K 

c 

c 
i 
i 
i 

c 

K 
i 

c 



*** 

*** 

ULP 

UL«> 

ULP 

ULP 

♦♦ZERO** 

**Z£RO** 

**# 

ULP 

**ZERO** 

ULP 

*** 

ULP 
ULP 

*** 

#** 
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8.0 NEW DATA TYPES 



the 

the 
define the 
from the IP 
ons see the 



C 



There are a number of options that may be included in 
IP datagram. These options will specified by the user of 
IP module. The following constants and types 
format of the options that are passed to and 
module. For more information about the use of opt 
OoD specification MIl-STH-1777. 

CONST 

lp_end = 0* 

ip_no » 1» 

ip_secur i ty « 2* 

ip_loose_route * 3* 

ip_ti west amp * 4* 

ip_recor d_r oute * 7* 

ip_streamid * 16* 

ip_str ict_route * 17* 

ip._max_ option * 31* 

ip_control_c 1 ass * 0* 

ip_debug_cl ass * ?„* 
ip_max._e I ass =3* 

ip_ loose ■ Ot 
ip_record ■ 1* 
ip_str let = 2* 



ip_ti me_onl y 
ip_record_addrs 

i p_st amp._addr s 



0> 
1* 

2* 



4\ 



TYPE 

i P_opt i on_r ec 

secur i ty : 

stream t 

routing * 

timing s 
RECEND; 



» RECORD 

io.secur i ty_r ec* 
i ©_str earn J d_rec» 
i p_rout ing.rec* 
i P_t iming_rec* 



ip_seeur i ty_rec * RECORD 



inuse 
s 

c 

h 
tec 

RECEND* 



BOOLEAN, 
O..OFFFF(16)* 
fj,.QFFFF( 16)* 
0..0FFFH1&)* 

0..0FFFFFFU6)* 
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8.0 NEW DATA TYPES 



lp,_str eamjd.rec * RECORD 
inuse J BOOLEAN, 
id : O..OFFFFC 16), 

RECEND, 



i p_r out i nq_r ec 



RECORD 



inuse 
rt y pe 

index 
count 
list 

RECEN0, 



BOOLEAN, 

Q..255, 

0..255, 

0..255, 

ARRAYtC 



61 



i p_ loose., i p_str ict 
0..8 

0..9 
OF ip_doubl e_word, 



i P _ 1 1 nsestamp 
inuse 
ttype 

index 
count 
ov er f I ow 

CASE 0..1 



■ RECORD 
BOOLEAN, 
0..255, 
G..235, 
0..255* 
0. .255, 

OF 



$o_ti we_only«. i o_stanip_addr s 

0. .3 
0..9 



c 
c 

£ 0..15 






*0* sffl_array 
=1= I S_ar r ay 
CASEND, 
RECEND, 



ARRAYC0..83 
ARRAYC0..3] 



OF ip.double_.word, 

OF ip_fu I I _st amp. 



c 



«P_fuM„sta?np = RECORD 

addrs ! i p_doub !e_word» 
time J !p_doub le_wrod» 

RECENO; 



The ICMP protocol uses IP datagrams to carry inforroat ion. 
The header of the IC^P datagram is defined by the following 
record. The currently defined values for the TYPE and CODE 
fields are also defined below. 

CONST 

icflip_echo_rep!y * 0, 

icrop_dest_unreachabl e * 3* 

ic!iip_source_quench » 4, 

i c n? p_ redirect =5, 

ic!*p_echo_reques t ~ 8, 

icir?p_t ifl?e_exceeded ■ 11, 

i ciJ!p_par an«eter_er ror * 12* 

icnsp_t ime_r equest = 13, 

icmp_t ime.r epl y * 14, 

icflip.i nfo_r equest « 15, 

icflrsp. i nf o.reply * 16, 
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icnsp^max $mut!_type 



* 255* 



lcdip_networfc_unreac^ab! e - 0* 

lcsp_host.unreachab1 e = !» 

i cmp_pr otoco !l_unr eachab I e « 2» 

icnsp^por t_unreachah! e » 3,» 

icmp_f r agreentat I on_needed * **> 

icffip_source_route_f a i f ed = 5> 

icn?p_t imeout * 0> 

icmp.ass«inb1 y_t i meout * 1; 



( 



^ 



TYPE 

icmp_h£ader_r3C 
error. type s 

error_code i 
checksum * 
CASE 0..2 OF 

gateway 
«1« 

ptr 

unused 
*2 S 

idsnt i f j gr 
sequence 

CASENQ, 
RECENC} 



= PACKED RECORD 
0..255, 
0,.255> 
0,.0FFFP(16)j 



1 p_doub le_word* 

0. .255, 
O..OFFFFFF<16)# 

0..QFFFFQ6), 

0..GFFFFU6), 






CONTROL DATA PRIVATE 



9-1 
OOD Internet Protocol FPS 

36/03/31 

9.C GLOSSARY 

; 

9.0 £LflSS££Y. 



The following term definitions are provided to aid the 
reader in understanding this document. 



£Qt*li Control Data Distributed Network 

Arch I tecture . 

Daiiaiasi This Is a block of ULP data oreceeded by 
an IP header and is the unit of data passed 
down by the IP module. 

UqBI Deoartroent of Defense. 

£££i Externa! Gateway Protocol. This protocol is 

used in the DoD network environment to pass 

simple routing information between individual 

f> catenets (see RFC-827* RFC-890.* and RFC-904), 

£J£i File Transfer Protocol. This is the protocol 

used in DoD systems to transfer files from 
host to host (see RFC-959), 

12.1 DoD Internet Protocol. This Is the level 

three protocol used by the DoD. It provides 
the serves of an OSI Internet layer. 

OSii Open System Interconnect. This is a model 

developed by the International Standards 
Organization (OSI) which defines a method of 
layering modules within networking software. 

££££&££li Each user of the IP module Is Identified 
by a specific protocol identifier. This 
identifier is referred to throughout this 
document as the protocol. 

5A£l 5ervice Access Point. A SAP is defined in 

this msnual as the point of access to the 
services that a module provides. In the case 
of the IP module this point of access is 
defined by a set of routine address provided 
by both sides of the service line. 



c 
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9.0 GLOSSARY 



J££i 



ya£i 



yi£i 



DoD transmission control protocol. This 
is the transport protocol used hy the DoD. 
TC° provides an error free orderly end to end 
data transmission (see MIL-STD-1778) . 

OoD user datagram protocol. This is a 
protocol which provides an single datagram 
transfer service with no promises (see 

RFC-768). 



User Level Pr otoco I • 
titles to indicate the 
being discussed. 



Used at various 
user of the module 



c 
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